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Description 

This invention relates to a system for authorising 
transactions, and to a method for adjusting the transac- 
tion limit in a terminal. 

A large percentage of transactions are now com- 
pleted using a transaction card, rather than cash or 
checks. A small but significant percentage of all such 
transactions generate losses due to improper usage of 
the cards. Such improper usage can include exceeding 
the credit limit of the card. The definition of improper use 
also includes continued purchasing while failing to pay 
monthly minimum charges. Various fraud scenarios also 
contribute to this loss. For example, purchases are 
made with cards that have been lost or stolen. In addi- 
tion, dishonest employees at a merchant can improperly 
create a transaction through the unauthorised use of an 
account number. 

Many approaches have been implemented to re- 
duce these losses. One of the earliest approaches used 
to combat these losses was to distribute a printed list of 
invalid cards. In use, the merchant would check the ac- 
count number on the card presented for the transaction 
with the account numbers printed in the list. If the ac- 
count number is listed, the transaction would be de- 
clined. 

The use of such a printed list is effective in reducing 
a large percentage of fraud losses. Unfortunately, this 
approach has a few drawbacks. For example, a trans- 
action card is often used almost immediately after it has 
been lost or stolen. This immediate use will occur before 
the card has been listed or before the list has been dis- 
tributed. 

Because of these difficulties, other, more sophisti- 
cated techniques have been implemented. One of the 
most effective schemes is to authorize every transaction 
through a real-time, on-line communication network. For 
example, an automated transaction terminal at the mer- 
chant can transmit the account number of the card pre- 
sented for a transaction to a central processor. The ac- 
count number of the card can then be checked against 
a current list of invalid card numbers stored either at the 
central processor or back at the card issuer. 

This on-line scheme eliminates the lag time inher- 
ent in distributing printed lists of invalid cards. Further- 
more, the cost of authorizing transactions is justified for 
high value transactions. However, for low value trans- 
actions, the losses tend to be lower and the benefits 
gained from on-line authorization do not justify the add- 
ed costs and delay involved in obtained an on-line ap- 
proval. 

Accordingly, various approaches have been devel- 
oped to authorize lower value transactions at the termi- 
nal, in an off-line manner. The simplest approach has 
been to provide the terminal with a transaction or "floor" 
limit. Any transaction having a value which is below that 
floor limit can be approved by the terminal. If the value 
of the transaction exceeds that floor limit, a request for 



authorization must be generated and transmitted to the 
central processor. 

The floor limit selected for a particular terminal has 
traditionally been based on the type of merchant estab- 
5 lishment and its location. The floor limit selected repre- 
sents an attempt to balance the level of loss which will 
occur for transactions that are authorized by the terminal 
with the cost of transmitting the requests to the central 
processor. 

In most systems, the issuer of the card has no con- 
trol over the floor limit. More recently, a system has been 
developed wherein both the issuer and the financial in- 
stitution that supplies the terminal to the merchant have 
a say as to the floor limit in the terminal. Such a system 
is described in European Patent No. 0 200 343. 

In this system, the terminal determines the transac- 
tion limit using data both stored in the terminal and data 
encoded on the transaction card. 

The data in the terminal used to calculate the trans- 
action limit is also determined by the type and location 
of the merchant. This information is fixed in the terminal. 
While this approach successfully reduces some fraud 
losses, it cannot accommodate short term changes in 
the patterns of loss which occur at a specific terminal. 
For example, if a new employee is dishonest or follows 
sloppy procedures, the tosses will immediately in- 
crease. Accordingly, it would be desirable to actively up- 
date the transaction limit in the terminal to maintain the 
desired balance between the level of risk and commu- 
nication costs. 

Another approach for reducing losses when a ter- 
minal authorizes transactions in an off-line mode is to 
provide the terminal with a list of invalid account num- 
bers. Such a system was disclosed in U.S. Patent No. 
3,696,335, issued October 3, 1 972 to Lemelson. The lat- 
ter approach required that the entire list of invalid cards 
be transmitted to the terminals. This approach has been 
found to be impractical because the list is quite long and 
therefore requires large data storage capacity in the ter- 
minals. The list would also take a long time to transmit 
to the terminals. 

Various suggestions have been made to overcome 
these problems. For example, U.S. Patent No. 
4,558,211, issued December 10, 1985 to Berstein 
teaches that the list can be reduced by geographical cri- 
teria. 

Still another approach which has been suggested 
is disclosed in U.S. Patent No. 4,943,707, issued July 
24, 1 990 to Boggan, and incorporated herein by refer- 
ence. In this patent, a system is disclosed for generating 
a data compressed version of the invalid card list. This 
data compressed version is much shorter and therefore 
requires less storage space in the terminal and can be 
transmitted faster. However, in certain cases, the cost 
of this approach still exceeds the benefits gained in re- 
duction of loss. Accordingly, it would be desirable to pro- 
vide other techniques for storing lists of potentially 
invalid cards which is not subject to any of the draw- 
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backs discussed above. 

Therefore, it is an object of the subject invention to 
provide an improved transaction approval system. 

It is another object of the subject invention to pro- 
vide a transaction terminal with enhancements for im- s 
proving the effectiveness of the authorization process. 

It is a further object of the subject invention to pro- 
vide a transaction approval system wherein the trans- 
action limit in the terminal can be varied. 

It is still another object of the subject invention to 
provide a transaction approval system wherein the 
transaction limit in the terminal can be adjusted to reflect 
a desired level of risk of loss. 

The present invention is defined by claims 1 and 7 
hereinafter, to which reference should now be made. 

The dependent Claims define further embodiments 
of the invention. 

In a preferred embodiment of the invention, long 
term and short term transaction histories are monitored. 

A certain amount of memory in the terminal can be 
devoted to storing account numbers which will provoke 
a request for on-line authorization information. The ac- 
count numbers are stored in three different lists. The first 
list is generated by the central processor and transmit- 
ted to the terminal. This list includes specific invalid ac- 
count numbers. This list can be a data compressed ver- 
sion of an invalid card list described above with respect 
to U.S. Patent No.4,943,707. The list is very short and 
includes only those invalid cards which had been report- 
ed actually used in the narrow geographical region 
where the terminal is located. 

The second and third lists are generated locally at 
the terminal and are based on activity at that terminal. 
The second list includes a record of account numbers 
from transactions that were forwarded to the central 
processor for authorization information and the central 
processor declined the transaction. Since this card is 
identified as at least suspicious, any subsequent uses 
should provoke an on-line request even if the transac- 
tion amount is below the transaction limit of the terminal. 
By placing the card on the second list, such an on-line 
request will be generated. 

The third list contains account numbers of cards for 
transactions where the transaction amount was below 
the transaction limit and was approved, off-line by the 
terminal. Once the account number is placed on this list, 
any subsequent uses of the card at that terminal will pro- 
voke an on-line request. This technique is intended to 
frustrate the fraud scenario wherein the card is repeat- 
edly used for many low value transactions in an effort to 
avoid detection. 

It should be noted that the concept of adding ac- 
count numbers to a terminal to provoke an on-line re- 
quest for authorization during a subsequent use is dis- 
closed in the above cited U.S. Patent No.4,943,707. 
However, in the system described in the latter patent, 
the account number was always added to the list if it had 
not been present in the list previously, regardless of 



whether the transaction was approved off-line. Thus, 
even if the transaction was forwarded for on-line author- 
ization because, for example, the transaction amount 
exceeded the transaction limit, the account number was 
still added to the list. It is believed that the latter ap- 
proach is not as efficient as that described herein where 
the account number is added to the list only if the trans- 
action is approved off-line by the terminal. 

Further objects and advantages of the subject in- 
vention will become apparent from the following detailed 
description taken in conjunction with the following draw- 
ings in which: 

Brief Description of the Drawings : 

Figure 1 is a block diagram of a transaction approval 
network of the subject invention. 

Figure 2 is a flow chart illustrating the steps per- 
formed during a transaction in a terminal operating in 
accordance with the subject invention. 

Detailed Description of the Preferred Embodiment 

Referring to Figure 1, there is illustrated an overall 
block diagram of a transaction approval network 1 0. The 
network 10 includes a central processor 1 2 which func- 
tions as communication node between financial institu- 
tions that issue transaction cards (issuers 14) and ter- 
minals 16. As shown in Figure 1, the terminals 16 can 
be directly connected to the central processor 12. In 
large transaction systems, there exists intermediate fi- 
nancial institutions and processors which act as inter- 
mediate communication nodes. For the purposes of de- 
scribing the subject invention, the intermediate commu- 
nication nodes can be considered transparent to the 
system. 

In existing systems, the central processor can route 
requests for authorization information generated at a 
terminal 16 to the issuer 14 of the transaction card. The 
issuer will determine if a particular transaction can be 
approved. An appropriate response is generated by the 
issuer and transmitted back to the terminal. 

If the issuer is unavailable, the central processor will 
act on the authorization request. To facilitate the evalu- 
ation of the transaction, the central processor maintains 
a list 20 of invalid cards, generated from information 
supplied by the issuers. The central processor consults 
that list in determining whether a particular transaction 
can be approved. 

As noted above, many existing transaction termi- 
nals are equipped to authorize a certain percentage of 
transactions in an off-line manner, without contacting 
the central processor. These existing terminals includes 
internal processors and electronic memories. The de- 
sign of such terminals is well known to those skilled in 
the art and need not be discussed. The subject invention 
can be implemented in latter type of terminals with the 
modifications discussed below. 
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In order to authorize the transaction locally, an ex- 
isting terminal will carry out a number of tests. For ex- 
ample, the terminal will determine if the card has expired 
by comparing the expiration date to the current date. 
The terminal can also determine if the account number 5 
is in an allowable format so that forged cards can be 
identified. 

The terminal will also determine if the transaction 
amount is below an internally set transaction limit. If the 
transaction amount exceeds the transaction limit, a re- 
quest for authorization information will be generated and 
transmitted to the central processor. The central proc- 
essor will supply a response to the terminal, based on 
information from its own data base or based on a com- 
munication with the issuer If the transaction amount is 
below the transaction limit, then the terminal can author- 
ize the transaction. 

As noted above, the transaction limit is typically 
fixed in the terminal. It is selected to control the risk of 
loss at a desired level. Terminals which are in locations 
which are subject to high loss will have a low transaction 
limit. If losses are very high, the transaction limit could 
even be set to zero to insure that all transactions are 
sent on-line for authorization. In contrast, terminals 
which are located at merchants where losses are low 
can have a high transaction limit, such as $50 or more. 

As noted above, the loss associated with low value 
transactions is not high. It has been determined that the 
average additional loss which can be expected when a 
twenty dollar purchase is not authorized in an on-line 
manner amounts to about four cents. In contrast, it costs 
about ten cents to obtain an on-line authorization. Thus, 
as long as the rate of risk of additional loss is maintained 
at a low level, it will be more cost effective to authorize 
low value transactions off-line. This goal can be 
achieved by dynamically adjusting the transaction limit 
in the terminal. The subject approach has the added 
benefit that off-line approvals are much faster and there- 
fore highly desirable in high volume, low value environ- 
ments. 

As noted above, in the prior art systems, the trans- 
action limit was selected and stored in the terminal 
based on past performance by the merchant and the lo- 
cation of merchant. It is believed that at least one system 
exists where the transaction limit can be downloaded to 
the terminal from a central source. However, even in the 
latter system, the criteria for selecting the transaction 
limit is only based on regional statistics. No effort is 
made to analyze the performance of specific terminals. 
Accordingly, no prior art system could respond to a 
change in the level of risk at a particular terminal. Such 
a change could result from the hiring of a dishonest em- 
ployee. 

The transaction limit in the terminal can be dynam- 
ically varied to maintain the desired balance between 
the level of risk and communication costs. In order to 
carry out this goal, the central processor must assess 
the transaction history at the terminal on a regular basis 



and compute the actual level of risk associated with 
those transactions. 

There presently exists transaction terminals which 
keep a record of all transactions. These terminals are 
referred to as data capture terminals. The transaction 
records are collected in a memory 28 and typically 
downloaded to the central processor, once a day, in a 
batch process. This information is used by the central 
processor to generate billing information which is then 
supplied to the respective issuers. The card issuers will 
then generate the bills that will be sent to the cardholder. 

As can be seen, a mechanism already exists for 
communicating the transaction records to the central 
processor. The central processor will now determine the 
number of transactions which have occurred at that ter- 
minal that are based on accounts in the master invalid 
card list 20. While debts created during many of these 
transactions will be ultimately collected, the likelihood 
that the debt will be uncollectible is quite high. If the level 
of risk posed by these recorded transactions differs from 
the desired level, the central processor can calculate a 
new transaction limit intended to adjust the level of risk 
to be closer to the desired level. This new transaction 
limit is then downloaded to the terminal and is stored in 
memory 30. The downloading process can be carried 
out during the existing data capture communication ses- 
sions. 

The central processor will store in memory 32, a 
record of the existing transaction limit for each terminal. 
The memory will also keep a record of both the long and 
short term history of the risk level at the terminal. For 
example, the processor will keep a count of the number 
of transactions at the terminal and the number of im- 
proper card usages. The short term count will keep a 
rolling total for several days, while the long term count 
will cover several weeks. Both of these records are up- 
dated each time data is received from the terminal. 

The analysis will be performed on all transactions, 
even those that were authorized on-line. In this manner, 
the system can detect an improper transaction that 
might have been approved on-line. The latter situation 
can occur if the transaction took place before a card was 
reported lost or stolen but was subsequently reported 
prior to the analysis by the central processor. 

The calculation process by the central processor 
will be based on a table of decision rules. If both the long 
and short term risk level are below a threshold, the trans- 
action limit could be increased. If either or both the long 
and short term risk level are above a threshold, the 
transaction limit can be adjusted downwardly. If it is de- 
termined that a new limit is necessary, that information 
can be downloaded to the terminal and recorded at the 
central processor during the next data capture session. 

In order to minimizes losses for transactions that 
have a value below the transaction limit, it is desirable 
to add procedures that will provoke a request for on-line 
authorization in situations where there is a heightened 
possibility that the transaction is fraudulent. One method 
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that has been suggested is to generate an on-line re- 
quest tor authorization when the value of the transaction 
falls in a small range just under the transaction limit. This 
approach can be used to prevent someone who has 
knowledge of the transaction limit from avoiding detec- s 
tion by restricting the value of purchases to amounts 
slightly less than the transaction limit. 

Another approach is to provide the terminal with a 
list of invalid cards. Various methods have been devel- 
oped to carry out this approach as disclosed in the 
above cited patents. Most of these approaches require 
a large amount of memory in the terminal. In addition, 
transmission of such lists takes a significant amount 
time. In the subject system, an attempt is made to derive 
similar benefits while reducing the memory storage and 
communication requirements. 

In the system, the terminal is further provided with 
a memory area 40 for storing lists of suspect cards. The 
account number of each card presented for the trans- 
action is compared to the account numbers in these 
lists. If the account number is present, the terminal will 
generate a request for authorization information from 
the central processor. 

Memory area 40 is subdivided into three lists. The 
first list 42 is generated by the central processor 1 2 and 
supplied to the terminal 16. This list contains invalid ac- 
count numbers and could be in the form described in 
EP-A-200343. However, the data compressed master 
table described in the latter patent might hold informa- 
tion about 100,000 invalid accounts and require 125 kil- 
obytes of memory. In the subject system, it is desirable 
that the entire memory 40 be only about 5 kilobytes in 
length. Various data compression algorithms can be 
used to maximize the storage capability of this memory 
space. 

The list generated by the central processor should 
be limited to a small subset of invalid cards that have 
been reported actually used in the narrow geographical 
area where the terminal is located. In addition, this list 
can be limited to cards that have been used in this type 
of terminal , which, as noted above, will most likely be 
placed in high volume, low value environments. As not- 
ed above, the subject invention includes a mechanism 
for daily reporting all of transaction activity from data 
capture terminals to the central processor. Thus, the 
central processor can compare the transaction records 
with its list of invalid cards and accurately compile a list 
of fraudulent cards that were used in a given region. 

Since the regional list compiled by the central proc- 
essor is limited to cards actually used it will be relatively 
small and can be transmitted quickly. Transmission time 
is further reduced by only transmitting new account 
numbers that appear on the list. These entries can be 
added to the list 42 in the terminal. When the region in 
memory storing the list is full, the oldest entry in terms 
of time can be deleted to make room for the most recent 
entry. Preferably, the parameters of the system are ar- 
ranged such that any entry will remain resident in the 



terminal an average of about three weeks. 

The remaining two regions in memory 40 include 
lists which are generated by and remain in the terminal. 
List 44 contains a list of accounts numbers which are 
associated with a transaction that provoked an on-line 
request for authorization information and the response 
from the central processor was to decline the transac- 
tion. In this case, the account number is clearly suspect 
and any future use of the card should be scrutinized. By 
placing the account number on this list, an on-line re- 
quest will be generated for each subsequent use of the 
account number even if the transaction amount is below 
the transaction limit. As with the first list 42, when the 
memory space is full, the oldest entry can be deleted to 
make room for the most current entry. 

The third list 46 contains account numbers of all 
cards which have been involved in transactions that 
have been approved off-line. By this approach, the sec- 
ond use of the card at that terminal will provoke an on- 
line request for authorization information. The system 
will therefore allow a single fraudulent use below the 
transaction limit but will stop a second use. It has been 
found that a common fraudulent activity pattern includes 
multiple low value transactions at a single terminal. Re- 
cording account numbers associated with transactions 
that have been approved off-line will prevent such a 
fraud scenario. Once again, when the list is full, the old- 
est entry can be deleted to make room for the most cur- 
rent entry. 

While multiple uses of a card at a single terminal for 
low value transactions is often associated with fraudu- 
lent activity, it is also quite common and legitimate in 
certain merchant situation. For example, a number of 
"fast food" restaurants are beginning to accept transac- 
tion cards for payment. It is not unusual for a customer 
to purchase food more than once a week from such a 
local establishment. 

In order to reduce the number of times such addi- 
tional low value transactions provoke an unnecessary 
on-line request for authorization, each account number 
in file 46 can further be provided with a data field indi- 
cating either the number of times it has been used or 
the date it was last used. If the data field is a usage coun- 
ter, the requests for on-line authorization can be made 
only during the second usage or for every other usage. 
If the data field indicates the date it was last used, an 
on-line request can be generated only if the last use was 
relatively recently. 

It should be understood that each terminal 16 can 
be provided with its own individual storage area 40. Al- 
ternatively, a single storage area 40 may be shared by 
a group of terminals at a given merchant location. 

Figure 2 is a flow chart illustrating the steps taken 
at a terminal 16 to authorize a transaction. At the start 
of the transaction, the card is swiped through the termi- 
nal so that identifying information encoded on the mag- 
netic stripe of the card can be read by the terminal The 
merchant will also enter the amount of the transaction. 
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In step 50, the terminal will carry out a number of 
initial tests to determine if the transaction can be ap- 
proved. As noted above, these tests will include a de- 
termination as to whether the card has expired. Assum- 
ing the initial hurdles are cleared, the terminal will com- 
pare the transaction amount to the transaction limit 
stored in memory 30 (step 52). In the preferred embod- 
iment, the transaction limit is dynamically adjusted on a 
regular basis by the central processor to maintain the 
level of risk close to the desired level. 

If the transaction amount exceeds the transaction 
limit, the terminal will generate and transmit a request 
for authorization information from the central processor 
in step 54. As noted above, either the central processor 
1 2 or the issuer 1 4 of the card will generate a response. 
In either case, a response will received by the terminal 
in step 56. 

The terminal will then determine if the transaction 
has been approved or declined in step 58. If it has been 
approved, the transaction can be completed in step 60. 
Typically a message which authorizes a transaction will 
include an authorization code which is recorded on the 
transaction receipt. 

If the transaction has been declined, the transaction 
will not be completed. In addition, the account number 
will be recorded in list 44 (step 62), By this arrangement, 
the next usage of that account number will provoke an 
on-line request for authorization even if the transaction 
amount is below the transaction limit 

Returning to step 52, if the transaction amount does 
not exceed the transaction limit, then the terminal must 
determine if the account number is present on any of 
the lists stored in memory 40 (step 64). If the account 
number is present, the terminal will generate a request 
foron-line authorization in step 54. The terminal will then 
follow the sequence described above. 

If the account number did not appear on any of the 
lists in memory 40, then the transaction can be complet- 
ed and approved off-line in step 66. In this case, the ter- 
minal will generate an authorization code which is re- 
corded on the transaction receipt. In accordance with 
the subject invention, since the transaction has been ap- 
proved off-line, the account number will also be added 
to list 46 so that a subsequent use of the card will pro- 
voke an on-line request for authorization information 
(step 68). As noted above, the terminal will keep a 
record of all transactions, whether they were authorized 
or declined. 

In summary, the transaction limit stored in the ter- 
minal can be dynamically adjusted to vary the level of 
risk at the terminal to be closer to the desired level of 
risk; and the terminal will generate and store a list of 
account numbers which might be invalid and should pro- 
voke an on-line request for authorization. 



Claims 

1. A system for authorising transactions, the system 
comprising a transaction approval network (10) 

5 having central processor means (12) for receiving 
and analysing transaction records for each of a plu- 
rality of remote transaction terminals (16) adapted 
to communicate with the central processor means 
(12) through the network (10), each transaction ter- 

10 minal (16) being adapted to authorise in an off-line 
mode transactions which satisfy tests carried out by 
the terminal (16) on the basis of authorisation infor- 
mation maintained in storage means provided 
therefor, and the terminal (16) being further adapted 

is to store in the storage means a record of the trans- 
actions handled by the terminal (16) and having 
transmitting and receiving means associated there- 
with for receiving information from and transmitting 
information to the central processor means (1 2), the 

20 information transmitted to the central processor 
means (12) including the record of transactions at 
the terminal (16), and the central processor means 
(12) being adapted to control the off-line mode of 
each terminal (16) by calculating a level of risk as- 

2$ sociated with the transactions record of the terminal 
(16) and, if the calculated level of risk differs from a 
desired level of risk, transmitting to the terminal (16) 
new off-line mode transaction authorisation infor- 
mation selected to adjust the level of risk at the ter- 

30 minal (16) towards the desired level of risk. 

2. A system according to claim 1 , characterised in that 
said central processor means (12) calculates for 
each terminal (16) the level of risk over two time in- 

35 tervals of differing length to determine whether the 
off-line mode transaction authorisation information 
should be changed. 



3. A system according to claim 1 , characterised in that 
40 the central processor means (1 2) calculates the lev- 
el of risk for each terminal (16) by comparing the 
transactions record of the terminal (16) with infor- 
mation about accounts associated with the transac- 
tions in the record. 

45 

4. A system according to claim 1 , characterised in that 
the network (1 0) is adapted to operate in response 
to the use of transactions cards, each transaction 
card having an account number, and in that each 

50 terminal (16) is such that one of the said tests (64) 
comprises carrying out a comparison of the trans- 
action amount presented for a transaction with a 
transaction limit included in the authorisation infor- 
mation and, if the transaction amount exceeds the 

55 transaction limit, the terminal (16) transmits a re- 
quest for authorisation to the central processor 
means (12), and if such request for authorisation is 
declined, the terminal (16) adds the account 
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number of the transaction card presented for that 
transaction to a list (44) stored in said storage 
means (40). 

5. A system according to claim 4, characterised in that s 
each terminal (16) is such that one of the said tests 
(64) comprises comparing the account number of a 
transaction card presented for a transaction with the 
said list (44) and a further list (46) of account num- 
bers of transaction cards, said further list (46) being 10 
stored in said storage means (40), and that, if (52) 

the transaction amount is not greater than the trans- 
action limit included in the said authorisation infor- 
mation and (64) the account number of the present- 
ed transaction card is not present in the said lists, 15 
the terminal (16) adds (68) the account number of 
the transaction card presented for that transaction 
to said further list (46) in said storage means (40) 
so that a subsequent use of that transaction card at 
that terminal (16) will result in the terminal (16) 20 
transmitting a request for authorisation to said cen- 
tral processor means (12). 

6. A system according to claim 4 or 5, characterised 

in that each terminal (1 6) is such that the maximum 25 
number of cards which can exist in the list is fixed 
and when that limit is reached, the account number 
oldest in the list is deleted to provide room for the 
next account number to be added to the list. 

30 

7. A method of operating a system for authorising 
transactions, the system comprising a transaction 
approval network (10) having a central processor 
(12) communicating with a plurality of remote trans- 
action terminals (16), the method comprising per- 35 
forming for each terminal (1 6) the steps of: 

receiving and storing at the location of the re- 
mote terminal (16) authorisation information for 
off-line mode transactions; 40 
operating the terminal (16) in an off-line mode 
to authorise a transaction thereat if the trans- 
action satisfies tests carried out by the terminal 
(16) on the basis of the stored authorisation in- 
formation; 45 

and controlling the off-line mode of operation 
of the terminal (16) by the steps of: 

producing at the terminal (16) a record of trans- so 
actions handled by the terminal (16); 
transmitting the transactions record from the 
terminal (16) to the central processor (12); and 
calculating at the central processor (12) a level 
of risk associated with the transactions record ss 
received from the terminal (16), and if the cal- 
culated level of risk differs from a desired level 
of risk, transmitting to the terminal (16) new off- 



line mode transaction authorisation information 
selected to adjust the level of risk at the terminal 
(16) towards the desired level of risk. 

8. A method according to claim 7, characterised in that 
the level of risk is calculated over two time intervals 
of differing length to determine whether the trans- 
action limit should be changed. 

9. A method according to claim 7, characterised in that 
the level of risk is calculated by comparing the trans- 
actions record with information about accounts as- 
sociated with the transactions. 

1 0. A method according to claim 7, characterised in that 
transactions are authorised on the basis of the use 
of transactions cards, each transaction card having 
an account number; and in that for each remote ter- 
minal (16): 

the authorisation information stored at the lo- 
cation of the terminal (16) includes a plurality of lists 
(42,44,46) of account numbers; 

and the operation at the terminal (16) includes 
the steps of: 

comparison of the account number of the card 
presented for a transaction with a first stored 
list (42) of invalid account numbers; 
requesting authorisation from the central proc- 
essor (1 2) for transactions which do not satisfy 
certain tests (52,64) based on the stored au- 
thorisation information, including a test (64) for 
absence of the account number in a second 
stored list (44); 

and, if any such request for authorisation is de- 
clined (58), adding the account number of the 
transaction card presented for that transaction 
to the said second stored list (44) so that a sub- 
sequent use of that transaction card at the ter- 
minal (16) will result in the terminal (16) going 
on-line to request authorisation from the central 
processor (12) even if the remainder (50,52) of 
the tests based on authorisation information 
are satisfied. 

11. A method according to claim 10, characterised in 
that the operation at each terminal (1 6) includes the 
step of: 

if all the tests (50,52,64) based on authorisa- 
tion information stored at the terminal (16) are sat- 
isfied, adding the account number of the transaction 
card presented for that transaction to a third stored 
list (46) so that a subsequent use of that transaction 
card at that terminal will result in the terminal going 
on-line to request authorisation from the central 
processor (12) if the remainder (50,52) of the tests 
based on authorisation information are satisfied, 
the said tests including a test (64) for absence of 
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the account number in the third stored list (46). 

12. A method according to any one of claims 7 to 11, 
characterised in that the authorisation information 
includes a transaction limit and in that the selection 
of the said new off-line mode transaction authorisa- 
tion information comprises calculation of a new 
transaction limit that adjusts the level of risk at the 
terminal (16) towards the desired level of risk. 



Patentanspruche 

1. System zum Genehmigen von Geschaften, mit ei- 
nem Geschaftsgenehmigungsnetzwerk (10), das 
eine zentrale Prozessoreinrichtung (12) hat zum 
Empfangen und Analysieren von Geschaftsauf- 
zeichnungen fur jedes von mehreren entfernten 
Geschaftsterminals (16), welches in der Lage ist, 
mit der zentralen Prozessoreinrichtung (12) uber 
das Netzwerk (10) zu verkehren, wobei jedes Ge- 
schaftsterminal (16) in der Lage ist, in einer Off-Li- 
ne-Betriebsart Geschafte zu genehmigen, die Tests 
bestehen, welche durch das Terminal (16) auf der 
Basis von Genehmigungsinformation durchgefuhrt 
werden, die in einer dafOr vorgesehenen Speicher- 
einrichtung aufbewahrt werden, und wobei das Ter- 
minal (16) weiter in der Lage ist, in der Speicherein- 
richtung eine Aufzeichnung der Geschafte zu spei- 
chern, die durch das Terminal (16) gehandhabt wer- 
den, und mit einer zugeordneten Sende- und Emp- 
fangseinrichtung versehen ist, um Information aus 
der zentralen Prozessoreinrichtung (12) zu emp- 
fangen und zu dieser zu senden, wobei die zu der 
zentralen Prozessoreinrichtung (12) gesendete In- 
formation die Aufzeichnung von Geschaften in dem 
Terminal (16) umfaBt und wobei die zentrale Pro- 
zessoreinrichtung (12) in der Lage ist, den Off-line- 
Betrieb jedes Terminals (16) zu steuern, indem sie 
einen Risikowert berechnet, der der Geschaftsauf- 
zeichnung des Terminals (16) zugeordnet ist, und, 
wenn sich der berechnete Risikowert von einem ge- 
wunschten Risikowert unterscheidet, eine neue Off- 
line-Betriebsart-Geschaftsgenehmigungsinforma- 
tton zu dem Terminal (16) zu senden, die so ausge- 
wahlt ist, daB der Risikowert in dem Terminal (16) 
auf den gewQnschten Risikowert eingestellt wird. 

2. System nach Anspruch 1 , dadurch gekennzeichnet, 
daB die zentrale Prozessoreinrichtung (12) fur je- 
des Terminal (16) den Risikowert uber zwei Zeitin- 
tervalle unterschiedlicher Lange berechnet, um 
festzustellen, ob die Off-line-Betriebsart-Ge- 
schaftsgenehmigungsinformation geandert werden 
sol It e. 

3. System nach Anspruch 1 , dadurch gekennzeichnet, 
daB die zentrale Prozessoreinrichtung (12) den Ri- 



sikowert fur jedes Terminal (16) durch Vergleichen 
der Geschaftsaufzeichnung des Terminals (16) mit 
Information uber Konten, die den Geschaften in der 
Aufzeichnung zugeordnet sind, berechnet. 

5 

4. System nach Anspruch 1 , dadurch gekennzeichnet, 
daft das Netzwerk (1 0) in der Lage ist, auf grund der 
Verwendung von Geschaftskarten zu arbeiten, wo- 
bei jede Geschaftskarte eine Kontonummer hat, 

w und daB jedes Terminal (1 6) so ausgebildet ist, daB 
einer der Tests (64) beinhaltet, einen Vergleich des 
Geschaitsbetrages, der fur ein G esc haft prasentiert 
wird, mit einem in der Genehmigungsinformation 
enthaltenen Geschaftsgrenzwert vorzunehmen, 

*5 und, wenn der Geschaftsbetrag den Geschafts- 
grenzwert ubersteigt, das Terminal (16) eine Ge- 
nehmigungsanforderung an die zentrale Prozes- 
soreinrichtung (12) sendet, und, wenn die angefor- 
derte Genehmigung abgelehnt wird, das Terminal 

20 (16) die Kontonummer der Geschaftskarte, die fur 
dieses Geschaft prasentiert worden ist, in eine Liste 
(44) in der Speichereinrichtung (40) eintragt. 

5. System nach Anspruch 4, dadurch gekennzeichnet, 
25 daB jedes Terminal (16) so ausgebildet ist, daB ei- 
ner der Tests (64) beinhaltet, die Kontonummer ei- 
ner Geschaftskarte, die fur ein Geschaft prasentiert 
wird, mit der Liste (44) und mit einer weiteren Liste 
(46) von Kontonummern von Geschaftskarten zu 

30 vergleichen, wobei die weitere Liste (46) in der 
Speichereinrichtung (40) gespeichert ist, und daB, 
wenn (52) der Geschaftsbetrag nicht groBeralsder 
Geschaftsgrenzwert ist, der in der Genehmigungs- 
information enthalten ist, und (64) die Kontonum- 

35 mer der prasentierten Geschaftskarte nicht in der 
Liste enthalten ist, das Terminal (16) die Kontonum- 
mer der fur dieses Geschaft prasentierten Ge- 
schaftskarte in die weitere Liste (46) in der Spei- 
chereinrichtung (40) eintragt (68), so daB eine an- 

40 schlieBende Benutzung dieser Geschaftskarte an 
diesem Terminal (16) dazu fuhren wird, daB das 
Terminal (16) eine Anforderung zur Genehmigung 
an die zentrale Prozessoreinrichtung (12) sendet. 

45 6. System nach Anspruch 4 Oder 5, dadurch gekenn- 
zeichnet, daB jedes Terminal (16) so ausgebildet 
ist, daB die maximale Anzahl von Karten, die in der 
Liste existieren kann, fest ist, und daB, wenn dieser 
Grenzwert erreicht wird, die alteste Kontonummer 

50 in der Liste geloscht wird, um Raum fur die nachste 
in die Liste einzutragende Kontonummer zu schaf- 
fen. 

7. Verfahren zum Betreiben eines Systems zum Ge- 
55 nehmigen von Geschaften, wobei das System ein 
Geschaftsgenehmigungsnetzwerk (10) umfaBt, 
das einen zentralen Prozessor (12) hat, der mit 
mehreren entfernten Geschaftsterminals (16) ver- 
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kehrt, wobei das Verfahren beinhattet, fur jedes Ter- 
minal (16) folgende Schritte auszufuhren: 

Empfangen und Spetchem von Genehmi- 
gungsinformation fur Geschafte in Off-line-Be- 
triebsart an dem Ort des entfernten Terminals 
(16); 

Betreiben des Terminals (16) in einer OfMine- 
Betriebsart, urn ein Geschaft an ihm zu geneh- 
migen, wenn das Geschaft Tests besteht, die 
durch das Terminal (1 6) auf der Basis der ge- 
speicherten Genehmigungsinformation durch- 
gefuhrt werden; und 

Steuern des Off-line-Betriebes des Terminals 
(16) durch die Schritte: Erzeugen einer Auf- 
zeichnung von durch das Terminal (16) ge- 
handhabten Geschaften in dem Terminal (16); 
Senden der Geschaftsaufzeichnung von dem 
Terminal (16) zu dem zentralen Prozessor (1 2); 
und Berechnen eines Risikowertes, der der aus 
dem Terminal (16) empfangenen Geschafts- 
aufzeichnung zugeordnet ist, in dem zentralen 
Prozessor (12), und, wenn sich der berechnete 
Risikowert von einem gewunschten Risikowert 
unterscheidet, Senden einer neuen Off-line- 
Betriebsart-Geschaftsgenehmigungsinforma- 
tion zu dem Terminal (16), die so ausgewahlt 
wird, daG der Risikowert in dem Terminal (16) 
auf den gewunschten Risikowert eingestellt 
wird. 

8. Verfahren nach Anspruch 7, dadurch gekennzeich- 
net, daG der Risikowert uber zwei Zeitintervalle un- 
terschiedlicher Lange berechnet wird, urn festzu- 
stellen, ob der Geschaftsgrenzwert geandert wer- 
den sol It e. 

9. Verfahren nach Anspruch 7, dadurch gekennzeich- 
net, daG der Risikowert durch Vergleichen der Ge- 
schaftsaufzeichnung mit Information uber den Ge- 
schaften zugeordnete Konten berechnet wird. 

10. Verfahren nach Anspruch 7, dadurch gekennzeich- 
net, daG die Geschafte auf der Basis der Benutzung 
von Geschaftskarten genehmigt werden, wobei je- 
de Geschaftskarte eine Kontonummer hat; und das 
fur jedes entfernte Terminal (16): 

die an dem Ort des Terminals (1 6) gespeicherte Ge- 
nehmigungsinformation mehrere Listen (42, 44, 46) 
von Kontonummern umfaGt; und 
der Betrieb des Terminals (16) die Schritte beinhal- 
tet: 

Vergleichen der Kontonummer der fur ein Ge- 
schaft prasentierten Karte mit einer ersten ge- 
speicherten Liste (42) von ungultigen Konto- 
nummern; 

Anfordern einer Genehmigung bei dem zentra- 



len Prozessor (12) fur Geschafte, die gewisse 
Tests (52, 64) auf der Basis der gespeicherten 
Genehmigungsinformation nicht bestehen, ein- 
schlieGHch eines Tests (64) auf Nichtvorhan- 
s densein der Kontonummer in einer zweiten ge- 

speicherten Liste (44); und 
wenn irgendeine derartige verlangte Genehmi- 
gung abgelehnt wird (58), Eintragen der Kon- 
tonummer der fur dieses Geschaft prasentier- 
10 ten Geschaftskarte in die zweite gespeicherte 

Liste (44), so daG eine spatere Benutzung die- 
ser Geschaftskarte an dem Terminal (16) dazu 
fuhren wird, daG das Terminal (16) direkt eine 
Genehmigung bei dem zentralen Prozessor 
is (12) anfordert, selbst wenn der Rest (50 t 52) 

der Tests auf der Basis der Geschaftsinforma- 
tion bestanden wird. 

11. Verfahren nach Anspruch 10, dadurch gekenn- 
20 zeichnet, daG der Betrieb jedes Terminals (16) die 

Schritte umfaGt: 

wenn alle Tests (50, 52, 64) auf der Basis von in 
dem Terminal (16) gespeicherter Genehmigungsin- 
formation bestanden werden, Eintragen der Konto- 

25 nummer der fur dieses Geschaft prasentierten Ge- 
schaftskarte in eine dritte gespeicherte Liste (46), 
so daG ein spaterer Gebrauch dieser Geschaftskar- 
te an diesem Terminal dazu fuhren wird, daG das 
Terminal direkt eine Genehmigung von dem zentra- 

30 |en Prozessor (1 2) verlangt, wenn der Rest (50, 52) 
der Tests auf der Basis der Genehmigungsinforma- 
tion bestanden wird, wobei die Tests einen Test (64) 
auf Nichtvorhandensein der Kontonummer in der 
dritten gespeicherten Liste (46) umfassen. 

35 

12. Verfahren nach einem der Anspruche 7 bis 11 , da- 
durch gekennzeichnet, daG die Genehmigungsin- 
formation einen Geschaftsgrenzwert umfaGt und 
daG die Auswahl der neuen Off-line-Betriebsart- 

40 Geschaftsgenehmigungsinformation die Berech- 
nung eines neuen Geschaftsgrenzwertes beinhal- 
tet, der den Risikowert an dem Terminal (16) auf 
den gewunschten Risikowert etnstellt. 



1. Systeme d'autorisation de transactions, systems 
comprenant un reseau d'acceptation de transac- 

50 tions (10) poss6dant un moyen de centre de traite- 
ment (12) pour la reception et Panalyse des enre- 
gistrements de transactions pour chaque poste 
d'une pluralite de termtnaux de transaction a distan- 
ce (16) preVus pour communiquer avec le moyen 

55 de centre de traitement (12) via le r6seau (10), cha- 
que terminal de transaction (16) etant prevu pour 
autoriser des transactions en mode local qui satis- 
font a des tests effectu6s par le terminal (16) sur la 



45 

Revendications 



10 



9 



17 



EP 0 485 090 B1 



18 



base d'une information d'autorisation conserves 
dans le moyen de stockage prevu k cet effet, at la 
terminal (16) etant prevu, de plus, pour stocker 
dans le moyen de stockage un enregistrement des 
transactions traitees par le terminal (16) et possS- 
dant un moyen demission et de reception associ6 
pour la reception d'une information et pour remis- 
sion d'une information vers le moyen de centre de 
traitement (12), ('information transmise au moyen 
de centre de traitement (12) comprenant Penregis- 
trement des transactions dans le terminal (16), et le 
moyen de centre de traitement (12) etant prevu 
pour commander le mode en local de chaque ter- 
minal (16) en calculant un niveau de risque associe 
k I'enregistrement des transactions du terminal (16) 
et, si le niveau de risque calcule differs d'un niveau 
de risque desire, en emettant vers le terminal (16) 
une nouvelte information d'autorisation de transac- 
tion, en mode local, s6lectionn6e pour renter le ni- 
veau de risque sur le terminal (1 6) sur le niveau de 
risque desire\ 

2. Systeme selon la revendication 1 , caract6ris6 en ce 
que ledit moyen de centre de traitement (1 2) calcule 
pour chaque terminal (16) le niveau de risque sur 
deux intervalles de temps de longueurs differentes 
afin de determiner si ('information d'autorisation de 
transaction en mode local doit etre modifiee. 

3. Systeme selon la revendication 1 , caracteris6 en ce 
que le moyen de centre de traitement (12) calcule 
le niveau de risque pour chaque terminal (16) en 
comparant I'enregistrement des transactions du ter- 
minal (16) avec une information sur les comptes as- 
socies aux transactions dans I'enregistrement. 

4. Systeme selon la revendication 1 , caracterise en ce 
que le reseau (10) est prevu pour fonctionner en 
reponse k I'utilisation de cartes de transaction, cha- 
que carte de transaction poss6dant un numero de 
compte, et en ce que chaque terminal (16) est tel 
qu'un desdits tests (64) comprend une comparai- 
son du montant de transaction presents pour une 
transaction avec une limite de transaction incluse 
dans ['information d'autorisation et, si le montant de 
la transaction depasse la limite de transaction, le 
terminal (1 6) emet une demande d'autorisation vers 
le moyen de centre de traitement (1 2), et si une telle 
demande d'autorisation est refus6e, le terminal (16) 
ajoute le numero de compte de la carte de transac- 
tion presented pour cette transaction k une liste (44) 
dans ledit moyen de stockage (40). 

5. Systeme selon la revendication 4, caracteris6 en ce 
que chaque terminal (16) est tel qu'un desdits tests 
(64) comprend la comparaison du numero de comp- 
te d'une carte de transaction presentee pour une 
transaction avec ladite liste (44) et une liste supp!6- 



mentaire (46) de numeros de compte des cartes de 
transaction, ladite liste supplemental re (46) etant 
stockee dans ledit moyen de stockage (40), et que, 
si (52) le montant de la transaction n'est pas sup6- 

s rieur k la limite de transaction incluse dans ladite 
information d'autorisation et (64) le numero de 
compte de la carte de transaction presentee n'est 
pas present dans lesdites listes, le terminal (16) 
ajoute (68) le numero de compte de la carte de tran- 

10 saction presentee pour cette transaction k ladite lis- 
te supplemental (46) dans ledit moyen de stocka- 
ge (40) de telle facon qu'une utilisation suivante de 
cette carte de transaction sur ce terminal (16) en- 
traine une transmission par le terminal (16) d'une 

is demande d'autorisation vers ledit moyen de centre 
de traitement (12). 

6. Systeme selon la revendication 4 ou 5, caractSrise 
en ce que chaque terminal (16) est tel que le nom- 

20 bre maximum de cartes pouvant exister dans la liste 
est fixe et iorsque cette limite estatteinte, le numsro 
de compte le plus ancien de la liste est efface pour 
faire de la place pour le numero de compte suivant 
k ajouter k la liste. 

25 

7. Procede de fonctionnement d'un systeme pour 
i'autorisation de transactions, le systeme compre- 
nant un reseau d'acceptation de transaction (10) 
possedant un centre de traitement (12) communi- 

30 quant avec une plurality de postes de transactions 
& distance (16), procede comprenant, pour chaque 
terminal (16), les etapes suivantes: 

la reception et le stockage sur la position du ter- 
35 minal k distance (16) d'une information d'auto- 

risation pour des transactions en mode local; 

le fonctionnement du terminal (1 6) en mode lo- 
cal afin d'autoriser une transaction si la transac- 
40 tion satisfait aux tests effectues par le terminal 

(16) sur la base de I'information d'autorisation 
stockee; 

et commandant le mode en local de fonction- 
45 nement du terminal (16) selon les etapes 
suivantes : 

la production dans le terminal (1 6) d'un enre- 
gistrement de transactions mani6es par le ter- 
so minal (16); 

la transmission de I'enregistrement des tran- 
sactions du terminal (16) vers le centre de trai- 
tement (12); et 

55 

le calcul dans le centre de traitement (12) d'un 
niveau de risque assocte k I'enregistrement 
des transactions recu du terminal (16) et si le 
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niveau calcule de risque d iff ere d'un niveau de 
risque d6sire\ la transmission au terminal (16) 
d'une nouvelle information d'autorisation de 
transaction, en mode local, selectionn6e pour 
regler le niveau de risque au terminal (16) sur 
le niveau de risque desire\ 

8. Proc6d6 selon la revendication 7, caract§ris6 en ce 
que le niveau de risque est calcule" sur deux inter- 
vals de temps de longueurs differentes afin de de- 
terminer si la limite de transaction doit etre modified. 

9. Proc6d6 selon la revendication 7, caractd ris6 en ce 
que le niveau de risque est calcule 1 en comparant 
I'enregistrement des transactions avec une infor- 
mation sur les comptes associes aux transactions. 

10. Proc6d6 selon la revendication 7, caract6ris6 en ce 
que les transactions sont autorisSes sur la base de 
I'utilisation des cartes de transaction, chaque carte 
de transaction possedant un num6ro de compte, et 
en ce que, pour chaque terminal a distance (16) : 

('information d'autorisation stocked sur la posi- 
tion du terminal (16) comprend une plurality de 
listes (42, 44, 46) de num6ros de comptes; 



si tous les tests (50, 52, 64) bases sur I'infor- 
mation d'autorisation stocked dans le terminal (16) 
sont satisfaits, ('addition du num6ro de compte de 
la carte de transaction pr6sent6e pour cette tran- 
saction a une troisieme liste stockee (46) de telle 
facon qu'une utilisation suivante de cette carte de 
transaction sur ce terminal entraine le passage en 
ligne du terminal afin de demander une autorisation 
au centre de traitement (12) si le reste (50, 52) des 
tests sur la base de ('information d'autorisation sont 
satisfaits, lesdits tests comprenant un test (64) sur 
I'absence du num6ro de compte dans la troisieme 
liste stocked (46). 

12. Proc6d6 selon Tune quelconque des revendications 
7 a 1 1 , caract6rise en ce Information d'autorisation 
comprend une limite de transaction et en ce que la 
selection de ladite nouvelle information d'autorisa- 
tion de transaction en mode local comprend le cal- 
cul d'une nouvelle limite de transaction r6glant le 
niveau de risque dans le terminal (16) sur le niveau 
de risque d6sire\ 
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et le fonctionnement du poste (16) comprend 
les stapes suivantes : 

30 

la comparaison du num6ro de compte de la car- 
te presentee pour une transaction avec une 
premiere liste stocked (42) de num6ros de 
comptes non valides; 

35 

la demande d'une autorisation a partir du cen- 
tre de traitement (12) pour des transactions qui 
n'ont pas passe certains tests (52, 64) sur la 
base de I'information d'autorisation stockee, 
comprenant un test (64) sur I'absence du nu- 40 
m6ro de compte dans une seconde liste stoc- 
kee (44); et 



si une quelconque telle demande d'autorisation 
est ref us£e (58), ('addition du numdro de comp- *s 
te de la carte de transaction presentee pour cet- 
te transaction a ladite seconde liste stocked 
(44) de telle facon qu'une utilisation suivante de 
cette carte de transaction sur le terminal (16) 
entraine un passage du terminal (16) en ligne so 
afin de demander une autorisation au centre de 
traitement (12) meme si le reste (50, 52) des 
tests sur la base de rinfonmation d'autorisation 
sont satisfaits. 

55 

11. Precede selon la revendication 10, caracteris6 en 
ce que le fonctionnement sur chaque terminal (16) 
comprend l'6tape suivante : 
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